The present invention generally relates to computer database storage systems and, more particularly, to a multi-model computer database storage system with integrated rule engine.
Rules serve to model business logic. A rule is an atomic statement (a statement which can""t be broken down to simpler statements) describing some aspect of the business""s operation. Rules serve as guides for managers and employees for how they should act and what they should do in certain situations. These rules can be stored in the computer system. By doing so, the rules are easily accessible by all employees. As modern businesses must be very dynamic, a central repository also allows for easy rule modification and update. A smart database can use the rules in this repository to control its execution. These rules can cover all aspects of the business, from when to reorder supplies to the diagnosis of medical illnesses. Some rules have no applicability to a smart database (such as employee dress code), while others are much easier to use through the implementation of a smart database (like a 10000 rule set diagnosing respiratory illnesses). We will focus on rules which can be used to control the database; however, our system will allow for all types of rules.
As we are talking about a potentially huge number of rules (millions for a hospital which has numerous medical diagnosis systems as well as administrative rules), we must have some way to organize them all. We do this through the use of business objects. A business object encapsulates all the rules controlling a particular aspect of the business.
When a rule influences the database, we say that it xe2x80x9cfiresxe2x80x9d. This is keeping with traditional expert system terminology. In order for a rule to fire, its condition must evaluate to true. The database may evaluate rules either implicitly or explicitly. While a rule, by itself, may be ambiguous as to when it is evaluated, its position in the set of business objects will dictate which way it is evaluated. In general, rules which are automatically evaluated control some aspects of the business whereas rules which are explicitly evaluated provide information for a query. Rules which provide information for a query are essentially the same as rules in expert systems. This aspect of our business rules engine is called a decision support system.
Decisions are often difficult to make. They require making seemingly ambiguous relations between the data. Fortunately, we can model this ambiguity in the form of fuzzy variables. For a certain piece of data, we may consider multiple values, and each value will have a certainty factor assigned to it. The mathematical operations relating these fuzzy variables are well defined.
Computers are not infallible because they are programmed by fallible creatures. Therefore, users will need to validate results after a query. A how and why mechanism will explain to the user why a particular decision was made. One of the advantages of the rules paradigm is that if the logic is flawed, the incorrect rule can be quickly and easily fixed. Sometimes the logic is not flawed, but just skewed. In this case, it usually means that two rules which are both contributing to a solution have incorrect weights. There will be a feedback mechanism such that users can identify if a decision was correct or incorrect. Based on that feedback, the relative weight of the rules will be adjusted. This is similar in mechanism to a neural network; however, a neural network is a xe2x80x9cblack-boxxe2x80x9d design. This mechanism will be overt and accessible to the rule set administrators.
Many times a decision must be made between various objects which must be evaluated on the basis of numerous properties. This problem usually falls under the classification of data mining. While these decisions can be modeled by rules, they often require an inordinate number of rules which is cumbersome at best. Instead, we can model these with a special type of rule, called a sorting rule. A sorting rule allows us to not only pick the best of class, but also a range, like the 5 best, or to even view all the data sorted by multiple values of varying importance.
While some values that we want to sort by, such as cost, have a well defined relation between values (a simple numeric greater than/less than), others, such as location, are not so well defined. Hence, we allow our users to create value maps, where they place the different values (such as city names) on a 2D (potentially 3D or maybe even 4D) grid to map the relative importance of one value towards another.
Some data, such as that often stored in blobs cannot be easily related even through maps. Therefore, we will also provide a neural network which can learn from the available data and assign according certain factors to various fields. We should provide neural nets which recognize the most common types of blobs, such as bodies of text, JPEGs or PNGs. Neural nets provide the additional advantage that they can deduce relations between fields of data that were not previously recognized.
What is interesting here is that we""ve gone from expert systems to neural nets, sometimes considered to be different ends of the AI spectrum. FIG. 1 illustrates this relationship.
We start at rule-centric programming. Rules use fuzzy variables to aid in decision support. Rules are also used to define patterns when doing data mining. Pattern searching also relies on fuzzy variables to define relations between the elements. Data mining can also take advantage of neural networks.
Given the technologies that comprise a smart database, we must consider what makes the database actually xe2x80x9csmartxe2x80x9d. A smart database is one which uses the knowledge base available to it (in the form of business objects and learned neural data) to reduce the workload of the user. It will also potentially increase their accuracy and precision. It does this by enforcing relations between the data, automatically filling in fields and providing recommendations to the user to aid in the decision making process.
Everything that has been proposed here is possible with today""s databases, except that the burden of providing a rules engine and/or neural network is put on the application programmer, who often has little experience with such components. Many rules can be handled with just triggers, except that many more do require a true rules engine, and we want a common interface for all rules. Further, most rules can be embedded in procedural code. However, that is where they are put today. But procedural code is difficult to maintain. Rules change often in today""s business marketplace, hence IS departments want to make changes in real-time to the rules. They do not want to recompile an application or take down the database to link in the new code.
Further, IS departments do not want to add rules until they are tested and known to work properly. For this reason, a smart database must provide an environment for testing and debugging rules before they are put into effect. This environment will integrate seamlessly with the rule editor and feedback mechanism such that rules can be edited while a debugging session is taking place, and those changes will be reflected immediately in the session. As this environment is meant for testing and debugging, it will operate on a replicate of the data so that the original data will not be adversely changed.
We need to provide this dynamic environment because today""s business environment is changing faster than anyone can keep up with. The rule-based environment relieves most of the burden off of IS departments, but we can aid IS departments even more with the addition of temporal information to rules. Temporal information allows rules to be in affect between certain times or after a certain date. This is particularly advantageous when a new policy takes effect sometime in the future, but we want to set up the database for the change now so that it automatically takes affect at the specified time.
The storage and use of temporal information means that we may have multiple versions of the same rule or business object. We handle these through the use of a rule repository. A repository of the different versions of a rule or business object has the added advantage that rules can be easily reverted to earlier versions (for instance, if an unforeseen problem arises with the new one). Furthermore, multiple people can work on the set of rules and business objects without interfering with each other.
The present invention is an integral part of a computerized database system. All existing business rules engines sit on top of a relational database as a separate component. This means that all database access must go through them, or else the rules will not be enforced. This extra layer to data access slows performance of the application using the database. This is especially true for access to data not affected by the rules. In the present invention, through the use of triggers, only access to data affected by rules will experience any slow down through a check by the business rules engine. An additional disadvantage to accessing a database through a prior art rules engine is that the user cannot use any of the unique features of the database. They are limited to the standard methods implemented by the rules engine. By integrating the database engine with the rules engine in the present invention, we overcome this disadvantage. In particular, this means the use of multiple models to access the data. Finally, integration with the database engine allows storage of fuzzy data types (which are very useful for rule-based processing) in the database.
Rules are stored in the database engine to speed access. Storage of the rules in the database also forms an inseparable link between the rules and the data they act on.
Three technologies that have been developed, or have developed significantly in the past 13 years are fuzzy queries, neural networks and graphical display technologies. We take advantage of all three in the present invention. Fuzzy queries allow the user to find data without making an exact match on the item. The relation between data items can either be intrinsic (i.e. if the data are integers, then 90 is closer to 100 than 10), or it can be defined through the use of a value map. A value map is a graphical representation of the possible data items, with the distance between the items indicating how closely related they are.
The present invention also introduces the concept of using a fuzzy query as a rule, which we call a xe2x80x9cSorting Rule.xe2x80x9d A Sorting Rule allows some or all of the data used in the execution of the rules engine to come from the result of a fuzzy query.
The present invention also integrates neural networks through their use as value maps in fuzzy queries. This means that, rather than make the user form a graphical representation of the data items, the neural network will form its own model of the relations between data items. This provides the advantages of freeing the user from doing additional work, potentially better accuracy in evaluating relationships, and the ability to infer the relationships between data items that were not present in the original data sample.
Neural networks are also used as rules. This is a revolutionary concept as researchers and developers of rules systems and neural networks have traditionally taken what they consider to be opposite views of AI. One way in which a rule can be used is to change the value of a variable, goal or set based on a set of inputs. A neural network can also change the value of a variable, goal or set based on a set of inputs. The difference is that a traditional rule defines in what way the variable, goal or set is changed by means of a set of statements in some type of language. A neural network determines, through training on examples of what an output should be given some input, how the input affects the output. Hence, the present invention allows the use of either traditional rules, defined through the use of statements in a language, or neural networks to define a rule.
Advances in display technology allow us to make the development of the rule-set easier. Specifically, the present invention allows the rules to be debugged in a graphical manner, where the user gets visual feedback from a diagram of the rules as to where in the execution of their rules they are. This provides additional advantages, such as fast retrieval of information on execution during execution.
In one form of the invention, a computer database storage system is disclosed, comprising a data storage medium adapted to store a plurality of pieces of information, at least one piece of data stored in the data storage medium, and at least one rule stored in the data storage medium, each said at least one rule comprising a premise, an action, wherein the action is performed if the premise is determined to be true, an alternate action, wherein the alternate action is performed if the premise is determined to be false, and a trigger, wherein the trigger causes evaluation of the premise upon the occurrence of a predetermined event.
A multi-model computer database storage system, comprising a data storage medium adapted to store a plurality of pieces of information; at least one piece of data stored in the data storage medium; and at least one rule stored in the data storage medium, each said at least one rule comprising a premise; an action, wherein the action is performed if the premise is determined to be true; an alternate action, wherein the alternate action is performed if the premise is determined to be false; and a trigger, wherein the trigger causes evaluation of the premise upon the occurrence of a predetermined event.
A multi-model computer database storage system, comprising a data storage medium adapted to store a plurality of pieces of information; at least one piece one piece of data stored in the data storage medium; at least one rule set stored in the data storage medium, each said at least one rule set comprising a plurality of rules that are each executed whenever said rule set is triggered; and at least one trigger, wherein each said at least one trigger causes execution of at least one of said rule sets upon the occurrence of a predetermined event.
A multi-model computer database storage system, comprising a data storage medium adapted to store a plurality of pieces of information; a plurality of data stored in the data storage medium according to a plurality of logical data models; at least one rule stored in the data storage medium; a database engine operative to store and retrieve data to and from the data storage medium according to any of the plurality of logical data models; and a rule engine integrated with the database engine such that said at least one rule can be executed in the context of any of the plurality of logical data models.
A multi-model computer database storage system, comprising a data storage medium adapted to store a plurality of pieces of information; at least one piece of data stored in the data storage medium; at least one rule stored in the data storage medium; and a trigger, wherein the trigger causes execution of at least one of the at least one rule upon the occurrence of a predetermined event that is not a change to the data.
A multi-model computer database storage system, comprising a database storage medium adapted to store a plurality of pieces of information; at least one piece of data stored in the data storage medium; at least one rule stored in the data storage medium; at least one trigger, wherein the at least one trigger causes execution of at least one of the at least one rule upon the ccurrence of a predetermined event; and a debugging tool operative to graphically display at least one of the at least one rule and at least one of the at least one piece of data and logical interconnections therebetween, wherein said display of a particular rule or data changes appearance as said particular rule is executed and said particular data is utilized in a rule execution.